A session initiation protocol (SIP) event notification system as disclosed in Request for Comments (RFC) 3265 includes a network architecture that permits SIP nodes to request notifications from remote nodes which indicate whether certain events (e.g., change in state information) have occurred in a given end node. Namely, SIP entities may subscribe to the state of a resource associated with a remote node (e.g., a watched subscriber or resource entity), and a notifier node/server associated with the remote node can send a notification if a state change occurs. For example, a SIP entity may send a SIP SUBSCRIBE message to request a SIP event subscription (e.g., a presence state subscription) to a notifier node that services the end node. A notifier node associated with the end node may then be configured to return the current state information (e.g., presence state information) of the node (and updates to the state information) up until the subscription expires. Notably, the SIP events model is a “soft state” model where subscriptions are not permanent and are configured to expire after a predefined amount of time and must be renewed by subsequent subscription (e.g., SIP SUBSCRIBE) messages.
In addition to providing SIP event information associated with watched subscribers or resources, a notifier node/server can also be adapted to provide watcher information (WINFO) to the watched subscriber or resource entity. Problems arise, however, in scenarios where multiple SIP event servers (e.g., presence state servers) are deployed to handle subscription request transactions related to a watched subscriber entity. Namely, responding to watcher information requests become difficult because there isn't a single SIP event server (e.g., a presence server) that has a complete view of all watcher entities that are subscribed to a particular watched entity. In short, multiple SIP event servers may be handling the subscription request transactions related to a single watched subscriber entity. This is particularly problematic because current specifications typically do not allow a watched subscriber entity to discover and contact the full set of servicing SIP event servers in order to acquire all of the watcher subscriber information associated with that requesting watched subscriber entity.
Due to the SIP event notification system's soft state model, other problems may arise in the event a notifier server fails. Any watcher subscriber serviced by the failed notifier server will not know that the notifier server is unavailable and therefore will be unable to receive any SIP event updates (e.g., presence state updates) until the watcher subscriber's SIP event subscription expires. This problematic situation is difficult to detect, especially if it is not unusual for the watcher subscriber to not receive SIP event update messages because the watched entity's status typically does not change. Thus, the problem may continue undetected by the watcher entity for the length of the SIP event subscription. Moreover, even if the watcher subscriber detects the problem and refreshes the subscription, a re-subscribe message may be needlessly sent to the failed notifier server.
Accordingly, there exists a need for improved methods, systems, and computer readable media for providing a failover measure using watcher information (WINFO) architecture.